Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

206
Visualizações
Red Hat Linux: "desactivar" la comprobación de cifrado

Tengo una implementación de Red Hat 6.5 Linux que usa LUKS para cifrar el sistema y, por razones que no son relevantes, me gustaría "desactivar" la comprobación de cifrado de arranque durante un período de tiempo. Se volverá a activar en algún momento, por lo que incluso si es posible eliminar el cifrado LUKS por completo, esa no es una solución que me interese.

Lo que quiero es proporcionar automáticamente la contraseña de LUKS en el arranque para que no sea necesario ingresarla manualmente; por lo tanto, lógicamente "apagar" el cifrado aunque todavía esté habilitado.

Ahora, si bien esto es sencillo para dispositivos secundarios, es decir. al crear un archivo de clave, aplicar el archivo de clave a los dispositivos encriptados y modificar /etc/crypttab para hacer referencia al archivo de clave, aún debe ingresar al menos una contraseña en el arranque, porque, si el dispositivo principal está encriptado con LUKS, entonces primero tiene que ser descifrado antes de que /etc/crypttab sea accesible.

Hay una forma que he visto de eliminar el requisito de ingresar la contraseña inicial, que es:

  1. crear un archivo clave
  2. aplicar el archivo clave al dispositivo cifrado, es decir. habilitar la clave para que el dispositivo sea descifrado
  3. Copie el archivo de clave en un dispositivo extraíble no cifrado (por ejemplo, una unidad flash)
  4. agregue rd.luks.key= ruta absoluta al archivo de clave : dispositivo extraíble no encriptado a la línea del kernel de arranque en /boot/grub/grub.conf
  5. En el arranque, asegúrese de que el dispositivo extraíble no cifrado esté insertado y pueda ser referenciado por el proceso de arranque.

Todo esto se ve bien, excepto que no quiero un dispositivo extraíble no encriptado involucrado. Simplemente quiero que el servidor arranque como si no estuviera encriptado.

La única forma que veo para lograr esto es reemplazar el dispositivo no cifrado extraíble con un dispositivo no cifrado normal . En cuyo caso, el proceso de arranque leería el dispositivo normal no cifrado , obtendría la clave y la usaría para descifrar los dispositivos cifrados... ¡hey, el cifrado está deshabilitado!

El único dispositivo que puedo encontrar en mi sistema que cumple con los criterios normales de dispositivos no cifrados es /dev/sda1, es decir. /boot, así que realicé los pasos anteriores con los pasos 3 y 4 de la siguiente manera:

  1. como anteriormente
  2. como anteriormente
  3. copie el archivo clave a /boot/keyfile.key
  4. agregar rd.luks.key=/boot/keyfile.key:/dev/sda1
  5. n / A

Desafortunadamente, parece que no puedo hacer que esto funcione.

Red Hat arranca y no se me pide una contraseña (como se esperaba), sin embargo, hacia el final del proceso de arranque, falla con "Pánico en el kernel: no se sincroniza: se intentó matar a init! ..."

Este comportamiento es idéntico cualquiera de los siguientes que use:

  • rd.luks.key=/boot/keyfile.key:/dev/sda1
  • rd.luks.key=/keyfile.key:/dev/sda1
  • rd.luks.key=/archivoclave.clave
  • rd.luks.key=/ algúnArchivoClaveQueConozcoNoExiste.key :/dev/sda1

Entonces mis preguntas son las siguientes:

  1. ¿Es posible lo que estoy tratando de hacer?
  2. Si es así, entonces...
    • ¿Dónde debo poner el archivo clave?
    • ¿Cuál es el valor rd.luks.key que debo usar para hacer referencia al archivo clave?

Gracias de antemano por cualquier ayuda

over 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

Después de mucho investigar, finalmente encontré la respuesta (que funciona tanto en CentOS 6.6 como en 7). Gracias a los siguientes 2 recursos en particular:

  • Deshabilitar el cifrado LUKS
  • RedHat Bug 751640 - dracut ignora el archivo de claves crypttab

Lo que hice fue lo siguiente (como usuario root):

 # insert a password into my chosen password file echo -n "anypassword" > /etc/mypasswdfile # instruct the LUKS device to take the password from my password file vi /etc/crypttab and replaced the 3rd parameter "none" with "/etc/mypasswdfile" # add my password file as a valid key for the luks device cryptsetup luksAddKey /dev/sda2 /etc/mypasswdfile # configure dracut to add the following 2 items to the initramfs (so accessible at boot) echo 'install_items="/etc/mypasswdfile /etc/crypttab"' > /etc/dracut.conf.d/99-mypwfile.conf # instruct dracut to apply the configuration dracut -f # reboot the server reboot

Y eso es. El servidor se reinicia sin solicitar una contraseña. (Esto se puede deshabilitar/habilitar a voluntad eliminando/agregando el archivo de claves del dispositivo LUKS a través del comando cryptsetup)

over 4 years ago · Santiago Trujillo Relatório

0

Nunca tuve la necesidad de esto, pero ciertamente puedo relacionarme con su utilidad. Entonces, su publicación me impulsó a revisar cómo se podría hacer esto, y la única forma que veo es obtener los scripts/detalles de desbloqueo en initramfs.

Este es un proceso mucho más fácil en distribuciones basadas en Debian, porque es posible inyectar scripts en initramfs a través de initramfs-tools... dinámicamente en el arranque. Ver esto y esto y esto

Las distribuciones basadas en RHEL requerirían el uso de dracut (en modo de recuperación) para reconstruir initramfs. Por lo tanto, creo que puede resolver este problema reconstruyendo initramfs e inyectando sus scripts de desbloqueo allí ... de esa manera podemos estar seguros de que su dispositivo raíz/arranque se haya desbloqueado antes de que el kernel necesite montarlos. Este hilo de Gentoo sugiere una forma de acceder y modificar los contenidos de initramfs. En cuanto a la mejor manera de inyectar sus scripts de desbloqueo en initramfs, no estoy seguro de eso.

Sin duda intentaré esto cuando esté menos ocupado. Suena algo bastante útil para poder configurar.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda